Minimal example:

@pyimport numpy as np
np.random.rand() #works now

Autocompletion works as well, i.e. np.random.<tab> gives a list of all available members of the python object.

Thanks. I was planning on waiting a little while to do this, so that we can:

• Drop 0.6 support.
• Deprecate all the old getindex methods. (Eventually they will be made equivalent to o[i] in Python once the deprecations are removed.)
• Deprecate @pyimport and pywrap since you can now just do np = pyimport("numpy")

Ok, I tried to implement all your comments. Replacing o.o by a new PyPtr(o::PyObject) method effected many files (in a trivial way). Locally, it passes all tests. (I'll add some new specific tests later)

I look forward to comments and suggestions.

Codecov Report

Merging #517 into master will decrease coverage by 1.09%.
The diff coverage is 46.66%.

@@           Coverage Diff           @@
##           master   #517     +/-   ##
=======================================
- Coverage   54.09%    53%   -1.1%     
=======================================
  Files          19     19             
  Lines        1525   1566     +41     
=======================================
+ Hits          825    830      +5     
- Misses        700    736     +36

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b9cca81...77736c8. Read the comment docs.

BTW, regarding your third point above, I really like the "@pyimport numpy as np" syntax because it's basically the same in python. Maybe we can keep it as syntactic sugar?

pywrap(::PyObject)::Module can be deprecated with this.
Since that was just a hack to pretend to have . overloading.

(I can't workout if that has been done, so many things in this package are called py.*wrap.*)

basically the same in python. Maybe we can keep it as syntactic sugar?

No. The only reason that sugar exists was the lack of dot overloading. Now you can do const np = pyimport("numpy") if you want, and there is no benefit to a second syntax.

I understand why the macro was necessary. But as I said, I would see a benefit in the second syntax because it's close to what you do in python (and this is a python interface). I won't push this point any further though.

Added some simple tests. What should I do next to move forward with this?

perfect, thanks for the amazing work on this PR!

Notice that most of my warnings come from files within PyPlot so someone else should open a PR there.

Ok, AFAICS this PR should now be technically mergable (let's see if the tests pass on Linux and MacOS as well). I fixed all the merge conflicts, deprecated the getindex and setindex! methods and fixed all corresponding internal deprecation warnings (at least those that show up in the tests).

However,

• the README.md should be revisited. I made some basic adjustments but I guess a proper revisit/rewrite of the relevant section would be appropriate. As I'm not a native english speaker, it might make sense for someone else to take care of that?
• I haven't tested the getindex -> getproperty changes in gui.jl because I'm on Windows.

Since it's already after midnight, I guess it's time to go to bed :)

The single appveyor fail seems to be a random network issue.

AppVeyor failure is an unrelated network glitch.

See #629 for remaining steps.

Big thanks to @crstnbr for the big merge!